Existing network management tools, such as Hewlett Packard's Open View Network Node Manager (“HP's NNM”), utilize graphical displays of network components and generally utilize color to relay information. These systems are generally used to manage and control networks, in which they generally provide notification of the status of network elements, particularly, failed elements. Networks are generally comprised of computer communications equipment, including, but not limited to, routers, switches hubs, and servers. HP's NNM can be viewed as being representative of the architecture and approach used by current commercial network management tools and, thus, is used herein to explain some of the problems with existing approaches.
These existing network management tools have a number of problems. Specifically, the displays are not helpful. Since color (shown as varying grey shades in FIGS. 1 and 2) is used to relay information, alarms can be hidden by an inappropriate color change threshold. In particular, as shown in FIGS. 1 and 2, HP's NNM maps use shapes that represent collections or managed objects. As shown in FIGS. 1 and 2, each object can be ‘exploded’ by opening the object until the lowest level is reached. Each aggregate object can have only one (1) of six (6) colors to represent the number of elements grouped together in that aggregate object that are in alarm condition, the color of the aggregate object being determined on a fractional basis. Consequently, in certain circumstances, HP's NNM maps fail to communicate the occurrence of an alarm, as the presentation mechanism fails to relay the information to the user of the system in a way that makes the new failure apparent. For example, it may require the user to open additional windows, which, at a certain point, becomes impractical. At the aggregate object layer, as shown in FIGS. 1 and 2, the overall color of the aggregate object may not actually change color, even though individual elements of a specific aggregate object may fail.
Specifically, FIG. 1 is a typical view of an application of HP NNM, as it appears on an engineer's monitor, with one alarm and FIG. 2 is a typical view of an application of HP NNM, as it appears on a computer monitor, with multiple alarms. It is difficult to track the number of alarms in both FIGS. 1 and 2, especially in FIG. 2. The upper let-hand sub-window, which is labeled “IP Internet,” has not changed colors (or grey shades) in between FIG. 1 and 2, which illustrates how changes can be hidden. The color level did not change with the additional alarm, due to the number of objects represented below the “IP Internet” symbol (shown in the sub-windows below) that were not in an alarm condition. Since these maps can be many levels deep, this problem can occur at any level. Additional sub-windows must be opened to avoid the averaging problem, which makes the overall display extremely crowded. Similarly, new alarms in existing systems can be hard to see or detect. Even if the change of status in an individual element does, in fact, change the color of the aggregate object, the change in color can be hard to detect on the display. For example, displays used in these modern systems are typically filled with numerous colored objects and the operator may not notice one more colored icon.
Also, information displayed by modern systems are difficult to relate or otherwise view. Particularly, the objects used in these modern systems are capable of relating only a limited amount of textual data. For instance, please refer to FIGS. 3 and 4. FIG. 3 is a typical view of HP's NNM, as it appears on a computer monitor, showing external data capabilities. FIG. 4 is a typical view of HP's NNM, as it appears on a computer monitor, showing internal data capabilities. A right click via a standard mouse on a symbol will bring up a menu of options, one of which is to view/modify the object description, but not the relative size of the comments section. This dialog box presents an opportunity to record some relevant external information about the symbol that is reporting the alarm, but, unfortunately, the opportunity is effectively wasted, since it is extremely difficult and time consuming to enter each field by hand and only one or two pieces of information can be shown at a time. For each device, several entries would be required and there may be 1000's to 100,000's of devices. Typically, the label for an object is generated by the HP's NNM application and is indicative of some data internal to HP's NNM and is not related to any external data such as city name or device name.
Furthermore, applications using existing systems are difficult to administer, as the preferred tools are complex and typically require specialized training just to operate the tool. Moreover, scalability is questionable and expensive, as there is a limit to the size of network that HP's NNM can manage, and even for small networks (<500 sites) the hardware and software licenses are expensive. Finally, modern systems are slow and limited in the total number sites that can be reviewed. For instance, actual embodiments of NNM has not been shown to work reliably for more than 500 sites. Actual embodiments of HP's NNM took from fifteen (15) minutes to hours to display information about failed devices and stopped functionally about once a week.
Existing designs and procedures have other problems as well.